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REMARKS 



Claim Rejection under 35 USC § 112 

Claims 1-18 have been rejected under 35 U.S.C. 112, first 
5 paragraph, as failing to comply with the written description 
requirement. More specifically, it is alleged that there is no 
support given from the original disclosure for the limitation 
"without the use of a broker" or "brokerless" in claims 1, 9 and 
12 . 

10 

On page 5, lines 20-23, it is stated as follows: 

"The invention is designed to allow Java applications to 
talk to .Net Remoting objects without any .Net components 
running on the Java platform and will be referred to as 
15 Ja.Net (Java-. Net Communication )." 

The above passage appears again on page 7, lines 3-7. 

"The first type of implementation of Ja.Net is one that 
allows Java objects to talk to .Net Remoting objects. In 
20 other words, a Java client is enabled to understand .Net 

Remoting protocols. Any supported transport protocol and 
data format supported by .Net Remoting can be used." 

On page 3, lines 11-16 the following is stated: 

25 

"This method of bridging allows Java clients to use the 
.Net Remoting protocol to interact with a Web Service 
running in the .Net Framework. This method also allows 
.Net Framework clients to communicate with Java-based 
30 applications using the .Net Remoting protocol. 

Clearly, the above passages describe a system, which does not 
require an intermediary or broker. The interaction by Java 
clients with a Web Service running in the .Net Framework is 
35 direct and requires no broker. Similarly, the interaction 

between .Net Framework clients with Java-based applications is 
also direct. Accordingly, the above-mentioned passages support 
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the language of inter-object communication "without the use of a 
broker" as in claim 1 or a "brokerless" system as in claim 9. 

Claim Rejection Under 3 5 U.S. C. § 103 

5 Claims 1-3 and 5-18 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Thomas et al . in view of IBM Technical 
Disclosure Bulletin (IBM TDB) , "Brokerless Object Network", No. 
NN960561 . 

10 In applying claim 1 to Thomas, it is stated that Thomas 

discloses a method for allowing objects in a first programming 
language to communicate with objects in a second programming 
language. To support this assertion the Examiner points to p. 
1, paragraph [0011] , lines 30-33 of Thomas, which says the 

15 following: 

"the client {using a first programming language) downloads 
the requested communication proxy and dynamically 
interacts, at runtime, with an Internet service (using a 
20 second programming language) using the requested 

communication proxy, the communication proxy being local to 
the client" 

The words in parenthesis are those of the Examiner. In Thomas, 
25 the client downloads the communication proxy from the Service. 
The client then interacts directly with the local communication 
proxy it has downloaded and the latter communicates directly 
with the Service on behalf of the Client using any protocol that 
the Service may provide such as CLR, Java, COM, etc. 

30 

In Applicant's invention, the Server sends metadata to the 
client who generates proxies from the metadata, which are then 
implemented on. the client. By generating its own proxies, 
Applicant can optimize and verify its applications in 
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development. It can also specify a protocol and a programming 
language . 

While both Thomas and Applicant receive metadata information, 
the metadata information of Thomas is sent by a broker to enable 
the client to locate the matched Internet Service communication 
proxy. The metadata in the present invention is received from a 
Java Server on a .Net Remoting client and used to generate .Net 
proxies. The .Net proxies are implemented on the .Net client. 



The IBM reference simply describes the operation of a Token Ring 
System of Communication among a number of objects. It describes 
how a second object of unknown location is located by a first 
object by passing a token around from node to node of a network 
15 until the token is loaded successfully, stripped from the ring, 
and the message responded to. This enables the two objects to 
communicate . 



The present application is concerned primarily with a system of 
20 communication between Java objects and .Net Remoting objects not 
just in one object locating another object so that communication 
can take place. Consequently, Thomas combined with IBM TDB does 
not render obvious any of independent claims 1, 9 or 12 . 



25 As stated in the previous amendment, claims 1, 9 and 12 all 
recite direct one-to-one mapping of .Net classes and Java 
classes. The mapping between classes is determined in advance, 
at compile time. Such mapping of classes is not discussed or 
suggested by Thomas, IBM TDB or Zhang. To Applicant's knowledge 

30 such one-to-one mapping has not been done before. 
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The one-to-one class matching of the present invention allows 
one to talk to a .Net Remoting object from Java without any .Net 
component running on the machine . 

5 In paragraph 2 of page 13 of the Official Action, the Examiner 
in interpreting the statement in paragraph [0011] , last 
sentence, states that it clearly indicates that in other 
embodiments it is advantageous for the client to actually 
generate the remote communications code. However, an indication 

10 that the client is relieved from having to develop a remote 
communication code does not say that in other embodiments the 
client must generate such a code. In fact, Thomas, in paragraph 
[0003], lines 7-13, emphasizes the advantage over the prior art 
of the client being able to specify a protocol and a 

15 language /component technology that makes the most sense for the 
client. In paragraph [0019] the last sentence does refer to an 
embodiment in which the Client 100 receives service description 
language information from Broker 102 and develops an 
application, its own communication code, to communicate with 

20 Service 104. However, the latter embodiment still depends on 

receiving information from a broker and does not mention one-to- 
one mapping . 



In paragraph 4 of page 14 of the Official Action, the statement 
25 "the matched Internet service communication proxy, " does not 
refer to one-to-one matching (or mapping) of classes from the 
second programming language to the first programming language. 
The foregoing statement merely refers to locating an Internet 
service which matches the request of the Client. Half-way down 
30 paragraph [0011] the full sentence in which the foregoing words 
appear is as follows: "The broker matches the client request 
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and an Internet service, and transmits metadata to the client 
enabling the client to locate the matched Internet service 
communication proxy. Clearly, the word "matched" relates to the 
earlier word "matches" and has been taken out of context. 

5 

Applicant respectfully solicits re-consideration of the claims 
of the present application which he submits are in condition for 
allowance . 

10 Respectfully submitted, 



Hall, Vande Sande & Pequignot, LLP 
20 10220 River Road, Suite 200 
Potomac, Maryland 
USA 20854 
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Matthew A. Pequignot 
Reg. No. 43,851 
Attorney for Applicant 
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